A serial-attached small computer system interface (SAS) protocol engine supporting a large number of outstanding input-output (I/O) tasks may require a large memory for maintaining I/O contexts associated with pending and in-process tasks. The term “I/O” may refer to a particular SAS device conversation. An I/O task context may comprise a set of parameters associated with the particular SAS device conversation, including link rate, device address, supported protocols, and status register contents, among others. As the size of the memory is increased a cost/performance trade-off may be required, particularly if the memory is accessed by multiple agents. A large, high-latency context memory accessed by both hardware and firmware resources may result. “Firmware” as used herein means processor cycles or processes from a host processor or from a general purpose processor located in the SAS device. “Hardware” refers to a hardware protocol engine located within the SAS device.
To reduce the penalty of accessing this memory, a design may implement local storage within a SAS transport layer to cache the I/O task context associated with a particular set of inbound or outbound frames. The task context can be read once from main memory and used multiple times without paying a read penalty again. A design implementing more than one lane may include a local cache for each lane accessible only by that lane. A data frame path between SAS devices may include device interfaces and may be referred to as a “lane.” Additional information related to the SAS environment may be found in SAS standards documents, including e.g., Serial Attached SCSI, Version 1.1, Revision 09d, May 30, 2005; SAS-1.1).
In a SAS narrow-port configuration, data frames for a given I/O may arrive on a particular lane. In a SAS wide-port configuration, however, multiple lanes may be simultaneously connected to a target device and receive data frames for an I/O associated with the target device. In a technique sometimes referred to as “lane hopping,” the data frames associated with the I/O may arrive on the multiple lanes.
In the wide-port lane-hopping case, a lane may be required to retrieve a task context associated with an I/O comprising a plurality of frames distributed across multiple lanes as the frames are processed in a sequential order of reception. The task context may be updated as each frame is processed, before a subsequent frame associated with the same I/O is processed. Because of the sequential nature of the frame processing, the task context must be migrated from lane to lane as the processing proceeds. Traditionally, this is done by flushing each lane's local context back to the main context memory, then reading it again from the next lane. This method adds significant read/write overhead to the frame processing operations.